In business applications such as supply chain planning it is often necessary to schedule certain planning jobs depending on previous changes of the underlying data. For example, it is necessary to recalculate a production plan and generation of purchase orders if new customer orders have been entered into the system or if existing customer orders have been modified (new quantities of ordered goods or change in requested shipment dates).
In order to reduce required recalculations, partitions can be utilized that define logical “planning areas” which can be re-planned more or less independently from each other. In most cases, a planning area may for example represent a material or product. It can be a semi-finished or finished product.
In order to reduce the recalculations, a logical “planning file entry” can be utilized for each planning area (i.e. a “net change flag”) which indicates whether a re-planning of the corresponding planning area is necessary. Each relevant change in the planning area results in the planning file entry being changed to the logical state “re-planning necessary”, whereas each re-planning on a planning area resets the planning file entry to a state “no re-planning necessary”. Such a flag makes it easier to determine whether a re-planning or recalculation is required. For example, a flag can be presented on a user interface in order to support the planning staff and it can be used by automatically scheduled planning jobs in order to improve their performance by avoiding unnecessary calculations with time-consuming inspections of the underlying data in the planning area. A planning file entry can be useful in connection with scenarios such as a factory with a huge amount of materials. With most scenarios, during one day, only a small percentage of the whole materials are typically affected by changes. As a result, it would be inefficient to re-plan all planning areas. By using a planning file entry, the process of re-planning can be restricted to those materials which really need a recalculation.
In arrangements in which no concurrency exists and all changes and all re-planning jobs are processed in a serial fashion, administration of planning file entries is a straightforward task. However, problems arise in when changes of underlying data and planning jobs can be executed unsynchronized and concurrently in parallel transactions. Such problems include:                Parallel changes on the same planning area causing the result of a re-planning job to be “outdated”. In other words, the re-planning-job may be outdated if it publishes the state “no re-planning necessary” at the end of its task because parallel changes may have occurred which have not been taken into account by the planning algorithm.        Parallel re-planning jobs operating on the same planning area can result in “outdated” entries. Such a scenario could occur as follows: Assume that the lot size for a certain material is 100 pieces and that two planners independently of each other enter a new customer order into their interactive planning application, one for the amount of 8 pieces, and the other for the amount of 13 pieces. At the same time, both planners submit a re-planning job in parallel. Due to the lot size of 100 pieces, each re-planning job creates a new purchase order for 100 pieces. As a result two new purchase orders for 100 pieces each are created although one would be enough. This scenario would not be a serious problem if it were guaranteed that the resulting logical state of the planning file entry was to indicate “re-planning necessary” thereby indicating that the planning is not accurate. Therefore, if such an alert were initiated, it would be possible to manually or automatically (during a subsequent planning job) correct this situation.        